home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2589 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.6 KB  |  62 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: chang.unx.sas.com!walker
  3. From: walker@chang.unx.sas.com (Doug Walker)
  4. Subject: Re: Is a real good mpeg player possible on the amiga ?
  5. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  6. Message-ID: <DM5HrH.IA4@unx.sas.com>
  7. Date: Fri, 2 Feb 1996 13:35:41 GMT
  8. X-Nntp-Posting-Host: chang.unx.sas.com
  9. References: <4e2gqu$5ca@caers3.unicaen.fr> <DLqtLz.FFL@unx.sas.com> <4eedlr$pte@maureen.teleport.com> <4efhj3$p7s@serpens.rhein.de>
  10. Organization: SAS Institute Inc.
  11.  
  12. In article <4efhj3$p7s@serpens.rhein.de>,
  13. Michael van Elst <mlelstv@serpens.rhein.de> wrote:
  14. >sschaem@teleport.com (Stephan Schaem) writes:
  15. >
  16. >> support all this correctly. YUV do not take the major amount
  17. >> of time, and could be overlap with write to the buffer.
  18. >
  19. >Actually it takes quite some time because you have to handle
  20. >pixels byte by byte. Overlaps to the buffer are often not possible
  21. >(there is no write buffer in Buster) and a separate copy pass
  22. >is often _faster_.
  23. >
  24. >> I played with a PC and the 8bit dither mode was the fastest...
  25. >
  26. >It is possible that they reduce the quality of the decoding to
  27. >get some more speed.
  28. >
  29.  
  30. I'm sure they do - in fact, NO reasonable-speed software player
  31. that I am aware of handles MPEG motion vectors perfectly.  To
  32. fully handle motion vectors, you need to handle half-pel 
  33. increments, which in the worst case would force you to
  34. average the values of four pels in the past reference frame
  35. and four pels in the future reference frame (assuming motion
  36. vectors in both X and Y that were not an even number of pels
  37. and both future and past references) for each pel.  This is 
  38. simply unreasonable to expect in software.  Many players 
  39. average only two values for each of the past and future 
  40. reference vectors, the diagonally- opposite ones; others 
  41. probably round off the half-pel and take whatever comes up.
  42. There are lots of other compromises that are typically made 
  43. for speed.
  44.  
  45. It is also probable that they spent a lot more time optimizing for
  46. 8-bit dither mode.  16-bit mode is a lot faster in our MPEG player,
  47. assuming you have a Pentium.  I don't know what is faster on a 486.
  48.  
  49. Remember that when you test a software player, you are testing the
  50. hardware it's running on, the software itself, and the codec it is
  51. using all at the same time.  Don't leap to conclusions about the
  52. codec when the problem may be in the implementation.
  53.  
  54. -- 
  55.   *****                    / walker@unx.sas.com
  56.  *|_o_o|\\     Doug Walker<  BIX, Portal: djwalker
  57.  *|. o.| ||                \ AOL: weissblau
  58.   | o  |//     
  59.   ====== 
  60. Any opinions expressed are mine, not those of SAS Institute, Inc.
  61.  
  62.